home *** CD-ROM | disk | FTP | other *** search
/ Nebula 2 / Nebula Two.iso / SourceCode / MiscKit1.7.1 / MiscKitArchive.mbox / mbox / 000144_misckit-reques…aska.et.byu.edu_Tue Mar 1 09:32 MST 1994.msg < prev    next >
Internet Message Format  |  1994-10-30  |  4KB
  1. Received: from yvax1.byu.edu by maine.et.byu.edu; Tue, 1 Mar 1994 09:32:17 -0700
  2. Received: from DIRECTORY-DAEMON by yvax.byu.edu (PMDF V4.3-5 #4169)
  3.  id <01H9GBHYJQV401D5QG@yvax.byu.edu>; Tue, 1 Mar 1994 09:30:29 MST
  4. Received: from alaska.et.byu.edu by yvax.byu.edu (PMDF V4.3-5 #4169)
  5.  id <01H9GB8CKRJ402JJIJ@yvax.byu.edu>; Tue, 1 Mar 1994 09:23:01 MST
  6. Received: from acs1.byu.edu by alaska.et.byu.edu; Tue, 1 Mar 1994 09:15:25 -0700
  7. Received: from DIRECTORY-DAEMON by yvax.byu.edu (PMDF V4.3-5 #4169)
  8.  id <01H9G99R88SW01D2TD@yvax.byu.edu>; Tue, 1 Mar 1994 08:26:45 MST
  9. Received: from alaska.et.byu.edu by yvax.byu.edu (PMDF V4.3-5 #4169)
  10.  id <01H9G992KUFK01CDQ2@yvax.byu.edu>; Tue, 1 Mar 1994 08:26:01 MST
  11. Received: by alaska.et.byu.edu; Tue, 1 Mar 1994 08:25:46 -0700
  12. Date: Tue, 01 Mar 1994 08:25:46 -0700
  13. From: yackd@alaska.et.byu.edu (Don Yacktman)
  14. Subject: Re:  App size
  15. To: misckit@byu.edu
  16. Message-id: <199403011525.IAA20843@alaska.et.byu.edu>
  17. Content-transfer-encoding: 7BIT
  18. Status: RO
  19.  
  20.  
  21. > I just started using the MiscKit, and I was wondering how much of an app
  22. > size increase there is.
  23.  
  24. You're 50-100k sounds like it is in the ballpark.  If you're doing
  25. dynamic linking/bundle loading it's toward the higher number for
  26. sure, above it in fact, but a completely stripped app still gains
  27. quite a bit.  This is one reason why I'd really love it if NeXT
  28. would allow us to do shlibs...the MiscKit is starting to see a lot
  29. of use and it would be nice if we could install it as a shlib.
  30. (Though that _is_ a bit of a complexity for users, which is a problem,
  31. and backward compatability is a bit of a pain, too...ack.)
  32.  
  33. The other possible solution is, as has been discussed a little bit,
  34. to create several separate libraries, and then have the user link
  35. in the ones that they need only.  The only objection I have to this
  36. is the matter of convenience:  it is a lot easier to just drop one
  37. lib into a project and know that it will just work than to have to
  38. figure out which object is in each lib and pick and choose one at
  39. a time.  Perhaps the best way to go is to create the monolithic
  40. library and several smaller libraries which amount to the big
  41. library broken up into bits.  Then, while initially developing, you
  42. just use the big guy.  When you're done, and know for sure which
  43. stuff you aren't using, then take the big lib out of the project
  44. and grab the little ones as needed to make the shipping binary.
  45. This wouldn't bother me too much because I've found that knowing I
  46. have the objects available--even though I may not initially plan
  47. on using them--often sparks me into adding extra features to an
  48. app that eventually do make use of the objects.  That's why I like
  49. the big library while doing initial development.
  50.  
  51. Well, I'm not sure what exactly the best way to attack the problem
  52. is, really.  The trouble is that if you link without the -ObjC
  53. flag, then you only get the objects that you reference and none
  54. of the Categories.  If you link with -ObjC you get _everything_,
  55. even stuff you will never use.  I'm not aware of a good way to
  56. tell the linker to do -ObjC but exclude specific files...though
  57. that would be the ideal solution IMHO.  That would require some
  58. Makefile.pramble hacking of OTHER_LDFLAGS, but would keep you
  59. from having zillions of libraries to link against.
  60.  
  61. Hmmm...the whole thing points up a problem with the linker really.
  62. The linker we have was designed for non-OOP languages and as such
  63. isn't able to deal with dynamic languages like ObjC.  (It can
  64. handle C++ fine since that's static...but...)  So you end up with
  65. an all or nothing, when you really want something in between.
  66. Right now, 50-100k isn't going to kill anyone too badly but when
  67. the MiscKit grows--if it keeps up a fair growth rate--it will
  68. become a problem.  Maybe we should convince NeXT that a whole
  69. new linking strategy would be nice.  :-)
  70.  
  71. Well, enough babble.  This is an interesting problem that I would
  72. like to do something about, but I'm not sure what the best
  73. approach would be given the state of the current tools.  Any
  74. suggestions, folks?  What would be best, all things considered?
  75.  
  76. Later,
  77. -don